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Introduction 


The American Radio Relay League (ARRL) is 
sponsoring this first international Amateur 
Radio Computer Networking Conference for se- 
veral reasons. One is to recognize the in- 
novative work that Canadian and U.S. ama- 
teurs have already done in packet radio. 
Another is to explore the possibilities of 
an integrated amateur packet network. As- 
suming that there is a consensus that a net- 
work can be developed, the third is to try 
to set up a framework for orderly growth. 


This paper outlines my current thinking 
on some aspects of amateur packet radio net- 
working. I have included a number of things 
that I believe should be considered at this 
conference and in the few months ahead. , 


Organization 


In the past year, there has developed an 
informal group of packet radio leaders from 
different clubs. Fortunately, these indi- 
viduals have been both advocates and doers. 
They have been in frequent touch with each 
other using various means of communication 
such as amateur radio, personal meetings, 
the mails and other methods. I 'm speaking 
mainly of: 


Stu Beal, VE3MWM 
Dave Borden, K8MMO 
Larry Kayser; VE3QB 
Doug Lockhart, VE7APU 
Hank Magnuski, KA6M 


Hamilton, ON 
Sterling, VA 
Ottawa, ON 
Vancouver, BC 
San Francisco, CA 


I would also like to be counted in this 
roup. I'm sorry if I left anyone out who 
eels that he/she should have been included. 
The above list is meant to include the per- 
sons acting as gateways between their clubs 
and most of the others. 


So far, this informal group has managed 
get the word around on new developments and 
has been able to move things along. 


In any new enterprise, there is a tenden- 
cy for someone to propose that the informal 
organization be replaced by a formal one. 

It is my feeling that this is a highly ex- 
perimental and dynamic endeavor aad that we 
shouldn’t fix what ' s working. 


Therefore, I suggest that we give at 
least tacit approval to this informal group 
and give them the ball on deciding when this 
leadership function needs to be formalized. 


Our organizational energies should be fo- 
cused, for the moment, on supporting the ex- 
isting organizations. As an individual, you 
should see to it that your club attracts new 
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members and helps them get on the air with 
packets. Virtually a.11 the clubs are gross- 
ly underfunded and could use help raising 
money, The club newsletters need more ca- 
pane writers on a variety of packet topics,, 
n addition, writers need’to send top quali- 
ty packet tutorials and technical articles 
to the ARRL publications gsr and gex. 


Network Management Issues 


Network architecture (structure, hierar- 
chy, protocol, routing strategies) needs to 
be ironed out soon. The Network Architec- 
ture Seminar of this conference should help 
to move this subject along toward some type 
of agreement. I personally favor a two-tier 
system. At the lower level, there would be 
Local Area Networks (each with their own re- 
pea ter), designed to fit the needs of the 
area. At the higher ievel, we would have 
a larger network (sometimes called an inter- 
net) which uses commonly agreed rules and 
can pass traffic via hf, satellite and ter- 
restrial circuits. Also, I feel it essen- 
tial to the network’s growth that a new sta- 
tion (terminal or network node) be able to 
fire up without begging someone’s permis- 
sion. 


Financing the network needs some fresh 
thinking. ndoubtedly, the local area net- 
works will be financed locally as are the 
numerous Z-meter fm repeaters. However, the 
internet needs both local an.d network-wide 
financing. The latter category may include 
a number of the following possibilities: 


eA network membership (users and sup- 
porters) fee on the order of $25 or more a 
year. 


eA fund such as the ARRL Foundation to 
appeal to all radio and computer amateurs. 


eProposals for seed money to government 
and/or industry. There is a. joint AMRAD/ 
ARRL proposal calling for sanding of 8 hf 
packet stations in its early stages of con- 
sideration by the U.S. Government. 


Applications of the network need to be 
thrashed out, The Applications Seminar of 
this conference should stimulate some new 
thought. For one thing, ] think that the 
network should develop a capability of 
handling third-party traffic. Serious con- 
sideration should be given to handling tele- 
typewriter (TTY) traffic for the deaf. 
Barry Strassler will present a paper on this 
subject. I believe that handling of deaf 
TTY traffic is feasible via a special type 
of computerized bulletin board (CBBS) de- 
veloped by AMRAD called HEX (Handicapped 
Educational Exchange) which speaks both 


ASCII and Baudot/Murray codes. In fact, we 
need to talk about the possibilility of 
interconnecting with al1 CBBS's in North 
America. This carries with it the problems 
of getting the individualistic system 
operators to understand the need to comply 
with the internet standards, Perhaps the 
knottier problem is how to screen all traf- 
fic to eliminate commercial and other no-no 
traffic before it is transmitted over Ama- 
teur Radio. 


Acronvmics 


Acronymics is a made-up word meaning 
playing around with acronyms. We need some 
agreed names to call things within the net- 
work. I was recently advised to leave this 
subject to discussion over beer and pizza. 
Ignoring that, here goes. 


First, I propose that the overall net- 
work be called AMNET. The term should spe- 
cifically apply to the internet and general- 
ly to the various Local Area Networks (LANs) 
connected to it. AMNET is meant to be an 
umbrella term. 


The internet will be made up of three 
transmission (sometimes called transport) 
systems, as outlined below: 


@ The satellite net, fortunately, has 
already been given an acronym: AMICON, 
standing for AMSAT International COmputer 
Network. In the interest of symmetry, maybe 
we should make the other transmission sys- 
tem acronyms end in CON. 


*The net of vhf/uhf packet repeaters 
along the countryside or terrain could be 
called TERRACON. 


*The high-frequency net uses the ion- 
sphere to skip long distances, so why not 
dub this SKIPCON? 


It would seem natural to follow commer- 
cial practice and call the stations that 
change from one net or medium to another 
gateways. I'm proposing to call these gate- 
ways: SKYGATE for satellite gateways, 
TERRAGATE for vhf/uhf gateways, and SKIPGATE 
for hf gateways. The need for SKYGATEs and 
SKIPGATEs is fairly obvious. But there 
could be TERRAGATEs too where there is need 
to change frequencies, data rates and per- 
haps protocols. 


I suggest that we leave the naming of the 
LANs to the local sponsors. It may also be 
necessary to name some virtual networks that 
people cook up within the network. Eventu- 
ally, I'd like to see all these names (fre- 
quencies and other parameters) published in 
a directory by the ARRL. The time will come 

uite soon when we will need a packet radio 
diyectory which lists all network facilities 
as well as individual packet radio stations. 
To kick this off, AMRAD is offering to col- 

lect the information and organize it in a 
directory form. We already have a CBBS Di- 
recto‘y hich could be included. 
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Internet Standards 


If the internet is to work it must have 
agreed standards. There must be agreement 
on a wide set of particulars including pro- 
tocols, routing strategies, radio frequen- 
cies, etc. Yet we need to temper this with 
maximum flexibility. There are a number of 
fundamental issues to be addressed. For 
example, do we want to look for government 
seed money and configure the network so that 
it can handle government traffic in emergen- 
cies; e.g., use ARPA's Internet protocol? 
Perhaps the other issues can be better 
handled according to the medium used: 


Vhf/uhf Terrestrial Net Standards 


This net should consist of a number of 
single-frequency vhf/uhf repeaters, each 
with a capability of working neighboring re- 
peaters on the same frequency. This can go 
on for an unlimited number of hops, or the 
chain can be broken by changing to another 
frequency. Propagationally, the 144, 220 or 
420 MHz amateur bands would be acceptable. 

I am inclined to push the 220-MHz band be- 
cause it is underutilized. Influencing the 
choice of frequencies may be the signaling 
speed permitted by the Federal Communica- 
tions Commission in the U.S. Current Rules 
permit only 1200 baud at 144 and 220 MHz and 
19.6 kilobaud at 420 MHz. 


What speeds should we use? In packet 
communications it is necessary to have a 
high enough signaling speed to handle the 
volume of traffic without the network going 
critical and being tied up permanently with 
retries. That says, "the higher speed the 
better." But, raising speed means increas- 
ing bandwidth (all other things equal) which 
means higher transmitter power for an accept- 
able signal-to-noise ratio. Certainly, 1200 
baud is not sufficient for such a net. 

2400 and 4800 baud are not that much better. 
9600 becomes marginally usable. From here, 
the American National Standards Institute 
(ANSI X3.36-1975) pegs the standard speeds 
at integral multiples of 8000 bits per se- 
cond, so the next speeds are: 16, 24, 32, 
40, 48, 56 kilobits, etc. ANSI shows 16 and 
56 as “selected standard signaling rates" 
and recognizes 48 kilobits per second as a 
recognized standard for international trans- 
mission. Thus, it looks like the choice for 
the high end is either 48 or 56 kb/s. The 
low-end choice seems to be 16 kb/s. I was 
pushing 48 kb/s because of its international 
blessing by the CCITT, but I have learned 
that very few circuits have been implemented 
at that speed and that modems are extremely 
rare/expensive. I suggest that we look very 
closely at 56 kb/s as a proposed standard. 
That still gives us a modem problem to be 
solved by amateur ingenuity. 


If we want to operate such speeds at 
220 MHz, we will need to petition the FCC 
for a Rules change. Probably the best ap- 
proach is to request a Special Temporary Au- 
thority (STA) as a first step. I believe 
that we want to ask for permission to use 


up to 56 kb/s in a portion of the 220-MHz 
band. You may have noted that the Canadians 
already have Department of Communications 
permission to use various bandwidths up to 
100 kHz in the 220-MHz band. Unfortunately, 
there is no simple method of equating band- 
width to signaling speed because things 
change with different modulation schemes. 
There has been a tendency for hams to think 
of fsk for transmission of data because we 
are used to sending RTTY that way. ‘The pro- 
blem is that fsk gobbles up too much band- 
width. Phase-shift keying (psk) conserves 
bandwidth, particularly if we can use 
quadraphase psk. There is much work to do 
on designing practical modems for these data 
rates. Commercial (say 56 kb/s) modems are 
far outside our price range. I'd like to 
see someone look into the design feasibility 
of a qpsk modem operating at a 10.7-MHz car- 
rier frequency for the internet repeaters. 


As for where in the 220-MEz band we 
should put these repeaters, I circulated an 
informal letter on this subject in May of 
this year. If you wish to research this 
problem, you should look at the Canadian 
Amateur Bands, !’*2 U.S. Amateur Radio Fre- 
quency Allocations,? and the ARRL Vhf-Uhf 
Advisory Committee 220-225-MHz band plan." 
Study of these references reveals that the 
220.0-220.5 subband is not usable because 
FCC rules do not permit repeaters. The FCC 
permits repeaters above 220.5 MHz. Starting 
at 221.9 MHz there is a weak-signal guard 
band, EME (moonbounce), propagational bea- 
cons, weak-signal cw, calling frequency, 

eneral operations (cw/ssb), as well as 

m repeaters and simplex channels to use 
up the higher part of the band, as out- 
lined in the band plan. So, that narrows 
packet repeater operation down to the sub- 
band 220.5 to.221.9 MHz in the U.S. This 
applies only to the internet repeaters or 
possibly local area net repeaters which use 
data rates above 1200 baud (with FCC STA or 
rules change, of course). Local repeaters 
using 1200 baud could operate on fm voice 
repeater or simplex frequencies in the 144, 
220 or 440-MHz bands. 


The proposed 220. 5-221.9-MHz internet 
packet repeater subband needs to be broken 
down into channels. Here’s my first cut; 
I'd welcome some comments: 


a. Channelize on 100-kHz inter- 
vals, e.g., 220.6, 220.7, etc. This will 
allow us to run up to 100 kHz bandwidth per 
channel. It will probably be necessary to 
keep two channels operating in the same 
area at least 400 kHz apart. Packet re- 
ceivers may use fm broadcast 10.7-MHz i-f 
transformers because of their low cost. 
Although fm broadcast band channel spacing 
is every 200 kHz, it is not usual to have 
adjacent channels allocated in the same 
area. 


b. As the arguments over whether 
to use simplex or duplex packet repeaters 
are not over, it might be prudent to look at 
the possibility of designating some duplex 
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channels within the 220. S-221. 9-MHz subband,, 
If the duplexer possibilities permit this, 
it would seem logical to have several duplex 
channels with inputs at one end and outputs 
at the other end of the subband. Then, the 
simplex packet channels could go in the 
middle: 


Frequencies Proposed Use 
220.6/221.6 Packet repeater pair 
220 fle be? tt 
220.8/221.8 " 

220.9 Packet repeater simplex 
221.0 ut 

221.1 " 

221.2 is 

221.3 u 

221.4 A 

221.5 ™ 


There is an immediate need for a group 
of people to work o:n terrestrial vhf/uhf re- 
peater standards and hardware design. Be- 
cause of the scarcity of commercial 220-MHz 
equipment with up to 100 kHz bandwidths and 
quick turn-around time, it appears that most 
220-MHz packet repeaters will be homebrewed. 
Doug Lockhart, VE7APU has circulated an in- 
formal paper which proposes certain design 
criteria. His basic idea is to come up with 
a single-board repeater that can be easily 
replicated across the continent. We need 
someone to undertake this design effort on 
a priority basis. 


AMICON Standards 


The focus of this work has been on the 
use of the data communications special ser- 
vice channel (L2) on the AMSAT Phase III 
satellite. There is already a committee in 
place headed by Hank Magnuski, KA6M. They 
have already drafted several generations of 
AMICON specifications which have been cir- 
culated to those directly involved. 


Hf Standards 


My concept is to have at least 8 hf 
gateways in the U.S., and about 6 in Canada. 
Within the bounds of ionospheric propaga- 
tion, all should be able to talk directly 
to each other. If not, some can relay. 


I would like to see the hf net run 
automatically, without human operators in- 
volved in sending and receiving packets. 
Computer control and digitally controllable 
rigs such as the ICOM IC-701/720 and the 
Collins KWM-380 permit this. A signal plan 
in software would provide the time slots 
with frequencies, antenna orientations and 
other information required for communica- 
tions between the then-active stations. 


Now, on to hf signaling speeds. Here 
is an area where we will. have to do some 
experimentation. The enemy is multipath. 

If you could always operate at the maximum 
usable frequency (muf) for the path, you 
could send at almost any speed because there 


would be only one path through the ionospher- 
ic layer. On the ham bands, it is not at all 
certain that you will be operating at or near 
the muf. Presently, the hf bands are alloca- 
ted every octave, the exception being the 21- 
MHz _ band which falls between the 14- and 28- 
MHz bands. The addition of the new WARC 
bands at 10 and 18 MHz will help this situa- 
tion for the longer paths. There remains an 
octave gap between the 3.5- and 7-MHz bands 
which will make it difficult for the shorter 
hf paths where multipath is a limiting fac- 
tor. (It would be nice to have a frequency 
near 5 MHz that could be used by hams for 
packet operations.) 


The worst-case situation on hf 
for multipath is in the vicinity of 100 km 
(near-vertical-incidence paths). Here, the 
maximum expected delay difference at fre- 
quencies below the muf could be about 8.5 ms, 
according to Salaman work on Multipath Reduc- 
tion Factor (MRF). 57 


MRF or delay difference is manifested 
by a new bit and old bit overlapping each 
other. The question becomes one of how much 
overlap can be tolerated before the signal is 
no lcnger readable. I suppose that the ane 
swer has a good deal to do with the decision- 
making process used in the demodulator and 
signal-processing circuits. Common sense 
would seem to lead one to conclude that 50% 
overlap is about as much as a receiving sys- 
tem could put up with. Laport says that the 
signal is mutilated when the prominent de- 
layed wave in the multipath group surpasses 
20%.” I suspect that a better number is some- 
where between these values. 
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Fig. 1 shows the maximum signaling 
rates in bauds as a function of path distance 
and operating frequency with respect to the 
muf. It is derived from Salaman's work. 

The conversion used to change delay in ms to 
bauds is based on a 50% overlap of code ele- 
ments. If you wish to believe the more pes- 
simistic 20%, then you can divide these 
rates by 2.5. 


I suggest that we recognize 75, 150 
and 300 baud rates as standard for hf packet 
operations. Also, we should begin experi- 
ments with 600 baud under an STA from the 
FCC in order to determine whether it should 
also become standard under a rules change. 
Initially, hf packet testing should use 75 
baud to iron out the other bugs. Then, 
testing of higher speeds should proceed un- 
der valid test methods capable of sorting 
out multipath from inadequacies of demodula- 
tors, etc. Operationally, it makes sense to 
operate at the highest speed at the time, 
consistent with ey copy. Assuming that 
we find the speed will vary under different 
path conditions, we should consider making 
the speed adaptive. By adaptive, I mean 
that signaling speed should be under soft- 
ware control so that the computers at each 
end can decide on which data rate is best 
for the prevailing conditions. 


Multipath distortion is not the only 
problem facing us on hf. Other types of 


fading, other signals, man-made noise and 
natural noise all conspire to prevent us 
from sending perfect packets through the 
ionosphere. 


Hams will make a substantial 
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contribution to technology if we can make 
this work reliably. Simply sending packets 
over an hf circuit will result in many re- 
tries (when conditions are not perfect). 
Nonetheless, 
order to get a feel for the problem. 
ever, it now looks very likely that we 
should use some type of forward error cor- 
rection (FEC). An FEC system called AMTOR, 
based on CCIR Recommendation 476, is cur- 
rently being tested overseas. & 
ber of U.S. 
experiment with AMTOR in November 1980 by 
the FCC.9 Jerry Dijak, W9JD is currently 
developing an hf FEC system,}0-11 
mains much work to do, both theoretically 
and experimentally. There are some inter- 
esting questions. One is, why do we keep 
throwing out packets which have one or 
more errors in them? Is it practical to 
compare two or three pretty good copies of 
a packet in memory and make a perfect one? 


How- 


We need some standard operating fre- 
quencies for hf packet communications. At 
this time, I believe that we need two fre- 
quencies per hf band -- one for network 
operations, one for direct use between in 
dividual stations (for experimentation, 
traffic handling, etc.). 


In February, 1981, I mailed an hf 


packet frequency survey request to a number 


of individuals in locations covering North 
America. Unfortunately, the response was 
not what [I had hoped. Rut, 
Bill, W4MIB and Pete, 
able number of hours that they monitored 
looking for activity on the RTITY bands. 
Their results, combined with mine, 
fairly consistent bell-shaped curve within 
the RTTY segments. 
conclusion that there were some good spots 
just inside the low and high ends of each 
RTITY subband. In addition to monitoring 
for on-the-air activity, research was done 
on published or other known usage./2 Also 
taken into account were: U.S. Fl alloca- 


tions, 3 Canadian Fl allocations,? the " on- 
siderate Operator’ Frequency Guide,"!3 and 


the IARU Region 1 HF Band Plan.!+4 


80 Meters: 
3500- 3775 U.S. Fl allocation 
3500- 3725 Canadian Fl allocation 
3610- 3630 Considerate Opr's Freq. Guide 
3580- 3620 IARU Region 1 HF Band Plan Fl 
Published or other known usage: 


some of that should be done in 


I wish to thank 
NSTP for the consider- 


showed a 


This led to the general 


3580 W1AW cw bulletins §& code practice 
3583 Southwest CW Traffic Net 
3585 Missouri CW Net 
3587.5 Louisiana RTTY Net 
3590 Empire Slow Speed Net 
Third Region Net 
Washington Section Net 
3595 Georgia State Net 
3596 Pine Tree Net 
3598 Southern California Net 
3600 Kentucky CW Traffic Net 
Kentucky Slow CW Traffic Net 
3602 First Region Net 
3605 Buckey Net RITY 


A small num- 
amateurs were granted an STA to 


There re- 
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3610 BFastern Pennsylvania CW Net 
Kansas CW Section Net 


Pennsylvania Training and Tfc Net 


3615 Louisiana Amateur Net 
3617.5 Virginia Specialized Comm. Net 
3620 AMSAT + RTITY Net 
Georgia Emergency RITY Net 
3625 WIAW RITY Bulletins 
3630 Kentucky RTTY Net 
Northern California Net 
3633 New Hampshire Net 
3635 Idaho Montana Net 


Tennessee CW Net 
3637.5 RITY Autostart 


40 Meters: 
7000- 7150 U.S. Fl allocation 
7000- 7150 Canadian Fl allocation 
7090- 7100 Considerate Oprts Freq. Guide 
7035- 7045 IARU Region 1 HF Band Plan Fl 


Published or other known usage: 


7040 Bastern Canada Net 
Hit §& Bounce Net 
7045 Ontario Southern Net 
IARU Region 1 HF Band Plan for SSTV 
7090 Forty Meter Interstate RITY Net 
Gater Net 
7095 W1AW RTTY Bulletins 


20 Meters: 
14000-14200 U S FI allocation 
14000-14100 Canadian Fl allocation 
14080-14100 Considerate Opr's Freq. Guide 
14080-14100 IARU Region ] HF Band Plan Fl 
Published or other known usage: 
14075 RTTY autostart 
14076.5 Canadian packet beacons 
14080 W1AW bulletins § code practice 
14082.5 Heath computers, autostart 
14095 W1AW RTTY bulletins 


15 Meters: 
21000-21250 U.S. Fl allocation 
21000-21100 Canadian Fl allocation 
21090-21100 Considerate Opr's Freq. Guide 
21080-21120 IARU Region 1 HF Band Plan Fl 
Published or other known usage: 
21095 W1AW RTITY bulletins 


10 Meters: 
28000-28500 U S Fl allocation 
28000-28100 Canadian Fl allocation 
28090-28100 Considerate Opr's Freq. Guide 
28050-28150 IARU Region 1 HF Band Plan Fl 
Published or other known usage: 


28080 W1LAW bulletins §& code practice 
28095 W1AW RTTY bulletins 

After review of all information avail- 
able, my recommendations for specific hf 
packet frequencies are: 

Band Direct Network 
80 meters 3612,5 kHz 3627.5 kHz 
40 meters 7 092 ,0 kHz 7098.0 kHz 
40 meters R1* 7036.0 kHz 7044.0 kHz 
20 meters 14076,5 kHz 14098.0 kHz 
15 meters 21092, 0 kHz 21098.0 kHz 
10 meters 28092.0 kHz 28098.0 kHz 


*R1 frequencies are for use in ITU Region I 
and for Transatlantic packet communications. 


Over the past few years, there has 
been a virtually complete phase-out of 850- 
Hz shift for hf fsk. The hf fsk standard is 
now 170 Hz. This has been somewhat of a 
mixed blessing. On the positive side, 170- 
Hz shift occupies less bandwidth thus con- 
serving spectrum in that sense. However, 
at 850-Hz shift, there was considerable de- 
correlation of the mark and space frequen- 
cies. In other words, the mark and space 
eee duet were so far apart that they 
tended to fade independently. This opened 
up the possibility of processing these two 
signals as two separate diversity branches. 
Diversity combining could give equivalent 
gains of something on the order of 8 dB or 
so depending on a number of factors. Ina 
way, this was moot because amateur RTTY de- 
modulators did not take advantages of this 
decorrelation when 850-Hz shift was used. 
I bring this up because we have another 
shot at it. Clearly, 170-Hz shift is not 
what we need to run data rates such as 300 
and (possibly) 600 baud. Bob Watson, a de- 
sign engineer who is working with state-of- 
the-art demodulation techniques, has given 
this problem a great deal of thought. He 
is proposing that we go to 600-Hz shift. 
This does a number of good things. 600 Hz 
is wide enough that mark and space tend to 
be decorrelated most of the time. It per- 
mits keying speeds up to 600 baud. It 
would allow us to use synchronous transmis- 
sion and reception. Frequency diversity and 
synchronous detection can provide consider- 
able gain. 


Local Area Net Standards 


For the most part, LAN standards seem to 
be developing along the lines of 1200 baud, 
Bell 202 modems, 2-meter simplex repeaters, 
using the VADCG terminal node controller 
board for the individual station, etc. Much 
of this has to do with the availability of 
the VADCG TNC boards and quantities of Bell 
202 modems. The 1200-baud data rate is also 
the highest speed presently authorized by 
the FCC for the 144 and 220 MHz bands. 


Things don't necessarily have to stay in 
this same pattern. In fact, there will de- 
velop a number of reasons why we should try 
some different techniques. If speed is a 
problem at 144 and 220 MHz, of course we can 
move to 420 MHz where the FCC permits 19600 
baud. Someone can make a pitch to the FCC 
to change their rules to allow higher data 
rates at 144 MHz and above. In fact, the 
ARRL has already done so under petition 
#3788. The availability of higher-speed 
surplus modems or an easily reproducible 
printed-circuit board designed by amateurs 
could make the higher-speed modem picture 
a bit brighter. A new board to replace the 
VADCG TNC could change things, possibly by 
reducing the cost. In other words, there is 
more than enough room to experiment. 


My basic point is that we need some com- 
monality to help local networks come about 
but need to encourage local experimentation 
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and innovation. 
Conclusion 


I hope that the foregoing information and 
recommendations contribute to the thinking 
processes in the development of amateur 
packet radio networking. Please understand 
that nothing that I have presented is cast in 
concrete. We are all learning. 


The time to design a packet network is 
now. Many of the people who will do the 
work are at this conference. We can muster 
the talent and resources needed to do the 
job. 


I would like to thank the ARRL, National 
Bureau of Standards, AMRAD membership, AMSAT 
membership, the Bureau Radio Amateur Signal 
Society and numerous individuals who have 
made this conference possible. 
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